1. Technical Field of the Invention
This invention generally relates to an interrupt handler for a computer system and, more particularly, to an interrupt handler coupled to a plurality of interrupt sources, this plurality of interrupt sources including interrupt sources that generate edge-triggered interrupt request signals received by the interrupt handler as well as interrupt sources that generate level-triggered interrupt request signals also received by the interrupt handler.
2. Description of Related Art
Many computer systems are designed to interface with one or more peripheral devices. A computer system typically includes a central processing unit (CPU) connected to a system bus having data, address, and control lines. The bus is connected to other computer system components, such as program memory, and also to peripheral devices via a suitable interface. The interface may include interface devices for translating voltages or signal formats for compatibility between the computer system and the peripheral devices. Suitable interface connectors are often employed. Communication between the CPU and the peripheral devices can include sensory or command information. Specifically, a peripheral device acting as a sensor may produce data signals indicative of parameters the peripheral sensing device is sensing, such as temperature, voltage, or other parameters. The data signals may be translated to a suitable form and read through the interface by the CPU to provide the CPU with needed data regarding the sensed parameters. Alternatively, the peripheral devices may be controllers. The CPU commands a peripheral controlling device by writing suitable commands through the interface to the peripheral controlling device. The device then takes suitable action in accordance with the command.
In a system including a plurality of peripheral devices, frequent or continuing communication between the CPU and the peripheral devices is often necessary. Various schemes have been used for keeping the CPU in touch with the peripheral devices. A first scheme is called polling. In a polling system, the CPU executes a polling routine at intervals of time. Typically, a hardware timer will cause the CPU to execute the polling routine periodically. During the polling routine, the CPU reads information from the peripheral devices indicating whether the status of a sensed parameter has changed or whether there is a need to send a command to the peripheral device. Depending on the information received from a given peripheral device during the polling routine, the CPU takes appropriate action, such as sending commands to the peripheral device or updating a record of the status of the peripheral device stored in computer system memory. Polling is commonly used in computer systems which interface with a large number of peripheral devices. However, polling has the disadvantage that the polling routine must be executed frequently, thereby consuming a large amount of CPU processing time. In many instances, the status information read from the peripheral devices indicates that no action is necessary. Thus, the time spent executing the polling routine in retrospect proves to be unproductive. In computer system involving a great deal of activity or real-time applications, the time spent repeating the polling routine can reduce processing efficiency.
As an alternative to polling, computer systems often service peripheral devices by means of interrupts. In an interrupt system, a peripheral device sends a signal called an interrupt request when a condition is detected requiring some type of action by the CPU. Many CPUs are designed to include interrupt request input lines. A CPU having such an interrupt request input responds to a predetermined voltage signal on the interrupt request line by executing an interrupt service routine. Thus, an interface between a CPU and a peripheral device can include circuitry which detects a change of status in the peripheral device for which service is required and provides a suitable interrupt request signal to the CPU.
An interrupt driven system of this type provides improved processing efficiency since interrupt routines are executed only when required. However, frequently a CPU will be employed to service a plurality of peripheral devices. In such a system, questions arise as to how to go about determining which peripheral device needs to be serviced in response to an interrupt request. Also, if several peripheral devices simultaneously provide interrupt request signals, there must be a way of determining which one is serviced first. In order to provide practical answers to these questions, programmable interrupt controllers have been designed and utilized in conjunction with computer systems. An interrupt controller typically has a single interrupt request output which is connected to the interrupt request input of the CPU. The interrupt controller also has a plurality of interrupt request inputs. Each interrupt request input is connected to a peripheral device. Thus, when the peripheral device requires servicing, it produces a suitable interrupt request signal which is received by the interrupt controller. The interrupt controller then interrupts the CPU and causes a suitable interrupt service routine to be executed.
A well-known example of an interrupt controller the 8259A programmable interrupt controller manufactured by Intel Corporation. The 8259A is designed to operate with two different types of microprocessors which support multiple interrupt request inputs in two different ways. The first type is exemplified by the Intel 8080/8085 microprocessors which service interrupt requests by executing a software sub-routine call instruction which has as an operand the address of the subroutine. The second type is exemplified by the Intel 8086 microprocessor which services interrupt requests by using an 8-bit vector to select an interrupt service routine address from a table of addresses stored in a contiguous area of memory. Depending on which type of microprocessor the 8259A is programmed for, in response to an interrupt request input, the 8259A will interrupt the CPU and provide either a subroutine call instruction followed by an interrupt service routine address or an eight bit interrupt vector over the system bus to the CPU. Thus, in either case, the 8259A provides the CPU with information as to which interrupt service routine to execute, thereby ensuring that the CPU services the peripheral device which requested the interrupt in a suitable manner.
The 8259A may be configured to detect interrupt requests on its interrupt request inputs as either low-to-high voltage transitions or as high voltage levels. In other words, the 8259A interrupt request inputs can be configured as either edge-triggered or level-triggered. Many peripheral devices have been designed to produce edge-triggered interrupt request signals in the form of low-to-high voltage transitions. Specifically, an edge-triggered interrupt request is a transition from a recognizably low voltage to a recognizably high voltage within a predetermined time limit. Peripheral devices which request service by means of high voltage levels are becoming more common.
However, programmable interrupt controllers to date have had the drawback that all interrupt request inputs are configured in the same manner. Typically, a single edge/level configuration control bit is used to program all interrupt request inputs to be either edge-triggered or level-triggered. This drawback has resulted in the disadvantage that upgrading a system to include peripheral devices producing level-triggered interrupt requests has required that all peripheral devices be so updated. It is not practical to employ a mix of level-triggered peripheral devices and older edge-triggered peripheral devices. Decreased flexibility and increased user costs have resulted.
In traditional arrangements, interrupt applications have permitted only level-triggered devices to have the same (identical) priority. Attempts have been made to integrate level-triggered request signals and edge-triggered request signals, but these have often involved assigning different priorities to level-triggered sources and to edge-triggered sources. These attempts often included statically multiplexing the sources of the level-triggered request signals and the edge-triggered request signals. In other efforts, the sources of the edge-triggered request signals were detached (or "degated") when a source of the level-triggered request signal activated. These methods share the problem of risking the loss of possible requests sent by the detached source.